Towards Autonomic Enterprise Security: Self-Defending Platforms, Distributed Detection, and Adaptive Feedback

Enterprises today face a constant barrage of security threats stemming from worms, viruses, trojans, and other malware. This is in spite of significant levels of investment in defenses such as firewalls and anti-virus and anti-spam products. Dealing with these attacks cost U.S. businesses over $67 billion last year. To make things worse, malware designers are staying slightly ahead of the game with a visible trend emerging of malware becoming stealthier and much harder to detect. Successfully mitigating security threats requires a multi-pronged approach that must include mechanisms that address different levels of the enterprise. Today’s enterprise networks are very complex because of the sheer number of heterogeneous enforcement points (involving multiple product lines from multiple vendors), the mobility of endpoints, and most importantly, the scale of the network itself (typical enterprise networks contain hundreds of thousands of hosts). Given these challenges, protecting the enterprise is a significant task, and relatively little work has been done in this area up to this point. In fact, enterprise policy management today is still largely a manual, ad-hoc process, lacking useful higher-level abstractions and a systems-level view in the application of security policies. In essence, there is very little autonomics today in the operational aspects of enterprise security management. In this paper, we argue that a successful strategy must not rely on silver-bullet-like approaches, but rather should target different levels of the enterprise. We describe three key building blocks that address different levels of the enterprise and show how these, when used together, provide truly autonomic security for the enterprise network. At the lowest level, we describe the notion of self-defending end-hosts, i.e., hosts that can detect integrity violations or subversion. We show how Intel Active Management Technology (Intel AMT) [18] and Intel Virtualization Technology (Intel VT-x) can be used to provide software integrity services and enable the end-host to regulate itself. At the next level, we describe how this capability can be significantly enhanced by allowing end-hosts to collaborate and detect network-wide anomalies (such as infections, attacks, etc.). Finally, we propose a feedback-based security management architecture for enterprise networks that views the enterprise at a higher level of abstraction. With these three capabilities, networks built using Intel platforms can provide autonomic control and protect themselves from day-zero threats, consistently, with enterprise security policies, and without intervention from administrators. Intel Technology Journal, Volume 10, Issue 4, 2006 Towards Autonomic Enterprise Security: Self-Defending Platforms, Distributed Detection, and Adaptive Feedback 286 INTRODUCTION Among the list of challenges faced by IT departments, security consistently ranks as one of the top year after year as reported by the Gartner Group. Firewalls, anti-virus software, and other similar protection mechanisms are ubiquitous in corporate networks. In spite of this, there is little respite from the spate of worm attacks, viral infections, host compromises, spyware, etc. It is estimated that protecting against these threats costs businesses about $67 billion a year, in the U.S. alone [8]. Among the myriad security threats that are seen today, worms and other kinds of self-propagating malware are, anecdotally at least, the single most challenging problem that the Internet faces. The homogeneous makeup of the Internet makes it very vulnerable to these kinds of attacks while its rich connectivity makes it very easy for worms to propagate. Thus far, state-of-the-art Intrusion Detection Systems (IDSs) have made use of the quickly spreading nature of these attacks to identify them with high sensitivity and at low false positive (FP) rates. However, in the race between worm designers and security vendors, the former always seem slightly ahead: there is a growing trend towards the use of stealthy worms that use evasion techniques to cloak their presence on an infected host. Such worms render existing IDSs ineffective. In addition, existing IDS products do not protect from day-zero exploits, which malware designers are adopting far more than in the past. In this paper, we first describe host-level protection, i.e., self-defending platforms, that can defeat (or at least detect) attacks that attempt to subvert the Operating System (OS). This is done using a runtime integrity service that automatically improves the security and robustness of networked platforms by leaving no place for malware to hide. We then describe distributed detection and inference, a method whereby protected systems can collaborate (or “gossip”) to detect (and signal) networkscale attacks (or infections). Untrusted systems cannot benefit from such gossip protocols as this network-wide information is secured by protecting the software on the end-point. Finally, we describe the adaptive feedback framework, a framework in which the “network state” as determined by the distributed detection can trigger feedback mechanisms to mount an automated response to day-zero threat conditions. The rationale for using network-wide information in our approach is also to enforce the autonomic response more intelligently, in a holistic manner, as compared to the more ad-hoc ‘per device type’ enforcement approach, and to target the most effective control points. Figure 1 shows a schematic of the entire architecture, showing how the three different mechanisms may interact with each other. Figure 1: Overall architecture of an Autonomic Enterprise Security system. The architecture consists of three mechanisms: (1) self-defending platforms protect individual end-hosts; (2) distributed detection correlates alarms across end-hosts; and (3) the adaptive framework delivers security polices (as a response to a network threat) to the most effective control points. SELF-DEFENDING PLATFORMS Our approach to create a self-defending platform leverages Intel Virtualization Technology (commonly known as VT-x) to efficiently enforce memory protections, and Intel Active Management Technology (Intel AMT) [18] to enforce network policies on the endpoint. We provide a brief background on VT-x for the sake of completeness. Interested readers can find a detailed description of this technology in this specification [1]. In the rest of this section, we assume that the reader is familiar with IA-32 instruction set architecture, the details of which can be found in the referenced Intel specification [2]. The term “virtualization” refers to the technique of partitioning a hardware platform into multiple virtual partitions called Virtual Machines (VMs) and running independent OSs in those virtual partitions. A layer of privileged software called the Virtual Machine Monitor (VMM) provides an abstraction of the hardware to each VM. At a high level, VT-x provides hardware support for virtualizing the CPU and the memory subsystem. By providing this hardware support, VT-x helps simplify VMMs, allowing them to support a wider range of legacy and future OSs without compromising performance or Intel Technology Journal, Volume 10, Issue 4, 2006 Towards Autonomic Enterprise Security: Self-Defending Platforms, Distributed Detection, and Adaptive Feedback 287 security. One of the key applications of the VMM is to maintain control over the physical memory of the platform. One way the VMM can achieve this on a VT-x CPU is by maintaining a set of parallel page tables for each OS running on the platform. The page tables maintained by the VMM are called the Active Page Tables (APTs). These page tables reference the real physical memory on the platform and are used by the processor for address translation. Each guest OS maintains its own page tables, called Guest Page Tables (GPTs). The VMM synchronizes APTs with GPTs in software using an algorithm called the Virtual TLB (VTLB) algorithm. The VTLB algorithm behaves similar to a processor Translation Lookaside Buffer (TLB). The algorithm relies on the VMM’s ability to trap events such as page faults and execution of certain instructions (for e.g., INVLPG, MOV CR3), that are used by a legacy OS to manage virtual memory. A detailed description of this algorithm is out of the scope of this paper, and interested readers are referred to [3] for further details. SELF-DEFENDING PLATFORM ARCHITECTURE We propose to build an autonomic platform with the following objectives: • Enable programs to securely specify their in-memory structure and access policies to the platform, including interaction with verified shared libraries and shared components. • After the program is recognized by the platform, detect changes to the program code/data. • Prevent use violation, by bugs or malware, by enforcing code entry at well-known offsets. • Prevent malware from root-kiting (invalidly hooking) critical services on the platform. • Self-remediate the platform when an attack is detected. Our architecture leverages privileges provided by VT-x to the VMM to monitor and protect software agents running inside a guest OS from other components of the same OS. This ensures that malware running in the guest OS is not able to tamper with critical software agents running in the same OS, even if the malware is able to achieve the highest privilege level within that OS. The VMM is measured at boot time as part of the measured boot sequence. Figure 2 shows the architectural overview. Figure 2: Self-defending end-point architecture All the agents that need protection implement a data structure called the Integrity Manifest (IM). The IM is cryptographically signed by the vendor or another trusted source and it describes the structure of the agent when it is loaded into memory correctly. Other components of the architecture include the following: • The Integrity Measurement Module (IMM) to use the IM to validate the agent in-memory. The IMM itself is part of an isolated secure partition in the platform such as a Service OS (VM). • The Verification Registration Module (VRM) to provide hyper calls for (de)registration. • The Memory Protection Module (MPM) to manage the page tables. At a high level, the setup phase for self-defense of software agents proceeds as follows: 1. The guest OS loads the software agent into memory and starts executing it. 2. The agent (or 3 party) registers with the VRM and requests memory protections. As a part of this registration request, the agent provides its IM to the VRM. 3. The VRM forwards the unauthenticated request along with the Manifest to the IMM. The IMM validates the signature of the manifest belongs to a trusted vendor or other source using a certificate authority signing hierarchy. Integrity of the manifest is then verified using this signature to ensure it was not modified. 4. The IMM uses highest privilege memory accesses to read the agent in the host physical memory, and it validates that the agent has not been altered, by comparing the agent’s loaded image with the IM’s description of that image [7]. Intel Technology Journal, Volume 10, Issue 4, 2006 Towards Autonomic Enterprise Security: Self-Defending Platforms, Distributed Detection, and Adaptive Feedback 288 5. If the IMM is able to validate that the agent is correctly loaded in memory, the VRM forwards the registration request to the memory protections module (MPM) 6. The MPM creates a Protected Page Table (PPT) for the agent code and data to protect the agent from runtime memory attacks. The MPM ensures this by removing the references to the agent’s code and data from the APT used by the OS. Once the setup described above is completed the MPM enforces various system policies such as preventing invalid jumps into the code and disallowing outside (nonagent code) read and/or write access into protected agent data. The MPM ensures that it can see all these events without risk of circumvention, due to the hardware virtualization capability of the processor. Specific events such as page faults cause transitions into the MPM that moderates these access attempts. We have prototyped this architecture on an Intel VT-x based platform with Intel’s lightweight VMM (LVMM) and used it to protect network drivers running in Windows XP guest OSs. STANDARDS FOR INTEGRITY MEASUREMENT The purpose of integrity measurement is three-fold: 1) to locate the program in host physical memory, 2) to verify that the program has been loaded into the memory without any tampering, and 3) to ensure that the program executes correctly. In this architecture, we propose a standard structure to enable runtime in-memory verification of the software agent in the IM. The IM data structure contains cryptographically verifiable information about each code and/or static data section of the binary program file that would be loaded to the memory. This includes cryptographic hashes [4] of the various sections that are to be verified. However, when the agents get loaded into memory, the OS performs relocation operations on these sections, in turn modifying the contents of these sections. Thus, to be able to verify the integrity of these sections at runtime, the IM includes information about locating and verifying these modifications were executed correctly. Specifically, the IM contains the following: 1. A cryptographic hash of the contents of each of the sections. 2. External symbols (functions or global data) that are referred to by the sections of interest. 3. Relocation entries that will be used by the OS to relocate the sections of interest (this enables the IMM to revert the relocation changes made by the OS, before the IMM computes the cryptographic hash for verification). 4. A list of allowed entry-points into the code (offset in a section). For example, each entry-point in a protected program may represent a function exported by the program. The IM has been proposed as a standard in the Trusted Computing Group for evaluating program integrity at runtime. Other auxiliary industry standards activities such as the TCG Trusted Network Connect (TNC) [5] and the IETF Network Endpoint Assessment group [6] can benefit from such a standard to attest platform integrity to the network. The combination of these standards with built-in platform integrity services allows for fully autonomic monitoring and verification of programs and their behavior at runtime. No user intervention is required to establish and maintain the proper execution of programs once protections have been enabled. Furthermore, the platform can automatically attest to the presence and status of the software executing on it to network access control mechanisms, report errors, or warn of possible attacks to trusted peers in the network, as we discuss next. DISTRIBUTED DETECTION AND INFERENCE As presented in the previous section, a secure platform is the best way to secure the enterprise, but it may take a long time for enterprises to upgrade all end systems. Therefore it is still important to have a reliable detection system throughout the enterprise. In this section, we describe a framework to combat the increasingly urgent problem of intrusion attempts within an enterprise. Traditional defenses have relied on perimeter mechanisms such as firewalls to protect the inside of an enterprise from external threats. However, the modern enterprise has very loosely defined boundaries and hosts are generally free to move in and out. Once infected hosts return into the enterprise, the infecting malware is free to spread relatively unchecked. Conventional detection schemes are based on observing traffic entering and leaving aggregation points around the enterprise. These schemes, while moderately successful, have several limitations, the most severe of which is that they are not very good at detecting slowly spreading worms that try to blend in with normal background traffic. The counter-measure that is often used for this type of worm is to use a variety of sensors around the network that measure and track different traffic features and that correlate one piece of information with another piece of information. Our framework extends this idea to the logical extreme: we Intel Technology Journal, Volume 10, Issue 4, 2006 Towards Autonomic Enterprise Security: Self-Defending Platforms, Distributed Detection, and Adaptive Feedback 289 consider each end-host in the enterprise to be a potential sensor (or Local Detector) and we allow the end-hosts to exchange information and corroborate the state of the network, i.e., whether it is infected or not. As we will show, such a system is able to detect slowly spreading network anomalies at a very low FP rate (which is much lower than those associated with conventional methods and tools). Briefly, there are several intuitive ideas for a collaborative, host-based framework: 1. IDSs deployed selectively might not see any worm traffic for a long time and perhaps see it only when it is too late. Collaboration is seen as a way to remedy this; systems that allow multiple IDSs to share information have been shown to provide greater “coverage” in detection [9, 10, 11, and 12]. 2. Analysis of network traffic at the host level allows the weak signal to be compared to a much smaller background noise-level, so the signal-to-noise ratio can be boosted by orders of magnitude compared to an IDS that operates within the network. 3. Host-based detectors can make use of a richer set of data, possibly using application data from the host as input into the local classifier. The detection and inference framework we describe here is quite simple: end-hosts contain Local Detectors (LDs) that are meant to detect anomalous behavior at the endhost. This could be by means of system integrity checks, watching outgoing network traffic, looking for anomalous behavior, etc. Periodically, the LDs gossip their local state (whether an anomaly was detected in some preceding window, or not) to other hosts. Some (or perhaps all) of the nodes in the network also contain Global Detectors (GDs). Their function is to aggregate the signals received from LDs (each GD receives signals from some number of LDs in the network). Thus, each GD computes the probability that a network-wide anomaly is occurring. In the rest of this section, we describe the LDs that we use and describe how information from different LDs is combined into a single measure. Subsequently, we describe simulation results that compare the performance of different models.